1. Field of the Invention
The present invention relates to a method for supporting Multicast Broadcast Multimedia Service (MBMS) service transmission in a mobile communication system Long-term evolution (hereinafter referred to as LTE) system proposed by the 3rd Generation Mobile Communication System Partnership Project (hereinafter referred to as 3GPP).
2. Description of the Related Art
FIG. 1 illustrates an example of an MBMS system structure. The MBMS network structure is based on a core network of General Packet Radio Service (hereinafter referred to as GPRS), and added with new network elements. Referring now to the MBMS system structure shown in FIG. 1, a Broadcast and Multicast Service Center (hereinafter referred to as BM-SC) (101) is the service control center of MBMS system. A Gateway GPRS Supporting Node 102 (hereinafter referred to as GGSN) and Service GPRS Supporting Node 103 (hereinafter referred to as SGSN) comprise the transmission network of MBMS service and provides a route for data transfer. Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network 104 (hereinafter referred to as UTRAN) provides radio resources for an MBMS service over the air-interface. User Equipment 105 (hereinafter referred to as UE) is a terminal device for data receiving. Home Location Register 106 (hereinafter referred to as HLR) saves user related data and provides services like user authentication. Uu 107 is a radio interface, and Iu 108 represents an interface between the access network and the core network. Iu resources used by MBMS service are not dedicated to one user, but for all users using this service.
FIG. 2 illustrates the sequence of a process in which an existing UE joins in the MBMS service.
Referring now to FIG. 2, in step 201, the UE initiates a process of establishing the Packet Data Protocol (PDP) context. Having been established successfully, the PDP Context is saved in the UE, SGSN and GGSN, and a signaling connection in PS domain is established between the UE and the GGSN. The intermediate devices for the signaling connection are the Radio Access Network (hereinafter referred to as RAN) and the SGSN.
In step 202, the UE transmits an Internet Multicast Management Protocol (hereinafter referred to as IGMP) join in message to the GGSN through the signaling connection established in step 201. The message includes a parameter of an IP multicast address for identifying a certain MBMS multicast service or certain multicast service in the external data network.
In step 203, the GGSN and BM-SC perform signaling interaction to authenticate the UE.
In step 204, GGSN sends a “MBMS Notification Request” message to the SGSN, which includes the parameters of the UE identifier and the IP multicast address.
In step 205, the SGSN sends to the UE a message requesting activation of the MBMS context after the SGSN receives the message in step 204. The message includes the UE identifier and the IP multicast address.
In step 206, the UE sends an “Activate MBMS Context Request” message to the SGSN after receiving the message in step 205. This message includes an IP multicast address, an Access Point Name (hereinafter referred to as APN), a MBMS_NSAPI (Network Service Access Point Identifier) and MBMS-bearing capacity of the UE.
In step 207, the SGSN sends a “MBMS Notification Response” message to the GGSN. This MBMS Notification Response message includes a cause value. The cause value indicates whether the MBMS context has activated successfully due to the SGSN or UE or not. Once receiving the response message of failure or the activation is timeout in the GGSN, the GGSN may return the IP Multicast Access (which is defined in 3GPP TS29.061).
In step 208, if necessary, a security encryption process can be carried out between the UE and the SGSN.
In step 209, the SGSN sends a request message for establishing the MBMS context to the GGSN, which includes the IP multicast address and an APN.
In step 210, the GGSN performs signaling interaction with the BM-SC to authenticate MBMS service and the UE after receiving the message in step 209.
In step 211, if the GGSN has not established the bearer context for the MBMS service yet, the GSSN sends an “MBMS Registration Request” message to the BM-SC. This MBMS Registration Request message includes an IP multicast address and an APN. The BM-SC sends an “MBMS Registration Response” message to the GGSN, which includes the MBMS bearer context information. BM-SC adds an identifier of the GGSN to a downlink node list of the BM-SC bearer context.
If a Temporary Mobile Group Identifier (hereinafter referred to as TMGI) has not yet been allocated to this MBMS service, the BM-SC allocates a new identifier, and transfers this identifier to the GGSN and the SGSN by the message of an “MBMS Registration Response”, and to the UE by the message of “Activate MBMS Context Accept” (215).
If the bearer context has been activated, a session start process between the BM-SC and the GGSN will be initiated by the BM-SC.
In step 212, the GGSN generates the MBMS UE context and transfers the “Create MBMS Context Response” message to the SGSN.
In step 213, if the SGSN has not yet established the bearer context for the MBMS service, the SGSN sends the “MBMS Registration Request” message to the GGSN. This message includes the IP multicast address and the APN. The GGSN sends the “MBMS Registration Response” message to the SGSN, including the MBMS bearer context information. The GGSN adds an identifier of this SGSN to the downlink node list of the GGSN bearer context.
In step 214, if at least one RAB in PS domain has been established for this UE, the SGSN transfers the MBMS UE context information to the RAN.
In step 215, the SGSN sends the “Activate MBMS context accept” message to the UE. It is not necessary to wait for the completion of step 212 to send this message by SGSN.
FIG. 3 illustrates the process of starting an existing MBMS. In step 301, the BM-SC sends a “Session Start Request” message to the GGSN in a downstream node list of MBMS bearer context, indicating the start of the transmission and offering the attributes of MBMS session such as the Temporary Mobile Group Identifier (hereinafter referred to as TMGI), the quality of service (hereinafter referred to as QoS), the MBMS service area, the session identifier, the estimated time period of the session, broadcast or multicast, etc. and 2G/3G (the 2nd or 3rd generation) indicator. The BM-SC sets the state of MBMS bearer context as activated. The GGSN creates the MBMS bearer context for the broadcast MBMS service. The GGSN saves session attributes and the downstream node list in the MBMS bearer context and sets the state of the bearer context as activated. The GGSN sends a “Session Start Response” message to the BM-SC.
In step 302, the GGSN sends a “MBMS Session Start Request” message to the SGSN in the downstream node list of MBMS bearer context. This message includes the session attributes such as the TMGI, the QoS, the MBMS service area, the session identifier, the estimated time period of the session, broadcast or multicast, etc. and 2G/3G indicator. The SGSN creates the MBMS bearer context for the broadcast MBMS service. The SGSN saves the session attributes and the 2G/3G indicator in the MBMS bearer context and sets the state of the bearer context as activated. The SGSN sends the “Session Start Response” message to the GGSN, including the Tunnel End Identifier (hereinafter referred to as TEID) through whose bearer plane GGSN transmits MBMS data. For one MBMS bearer service, if the SGSN receives several “MBMS session start request” messages, the SGSN establishes the bearer plane with only one GGSN.
In step 303, the SGSN sends the “MBMS Session Start Request” message to the BSC (Base Station Controller) and/or the RNC both connected with the SGSN. With the 2G/3G indicator, the SGSN indicates whether the “MBMS Session Start Request” message is sent to either BSCs or RNCs or both. This message includes session attributes such as the TMGI, the QoS, the MBMS service area, the session identifier, the estimated time period of the session, broadcast or multicast and so on. For the multicast bearer service, the SGSN includes the number of UEs that locate in each routing area (hereinafter referred to as RA) and has joined in MBMS service and stays in packet mobile management idle mode (hereinafter referred to as PMM-IDLE).
For the broadcast MBMS bearer service, the BSC/RNC creates the MBMS bearer context. The BSC/RNC in lu mode saves the session attributes in the MBMS service context, and sets the MBMS service context as activated state and sends the “MBMS Session Response” message to the SGSN. The RNC or BSC (which is in lu mode) includes TEID in the response message. TEID is used by the SGSN as the bearer plane for the transmission of MBMS data. To one MBMS bearer service, if the BSC or the RNC receives several “MBMS session start request” messages, it establishes the bearer plane with only one SGSN.
In step 304, the BSC/RNC establishes necessary radio resources to transmit the MBMS data to related UEs.
The existing MBMS UE connection process is illustrated in FIG. 4. The purpose of MBMS UE connection process is to report to the RNC whether the UE with lu packet domain signaling connection joins or leaves one or more MBMS services. Detailed descriptions on this process are given below.
In step 401, the CN sends a “MBMS UE Connection Request” message to the RNC. This message includes a TMGI list indicating whether the UE has joined in but is not connected with UTRAN, or the UE has left but not notified to UTRAN, a P2P Radio Access Bearer (hereinafter referred to RAB) Identifier.
In step 402, the RNC receives the “MBMS UE Connection Request” message. The RNC adds UE into the MBMS service context for the TMGI that indicates the UE has joined in but is not connected with UTRAN. If there is no MBMS service context, the RNC creates the corresponding one. If the UE is in the cell under the control of the DRNC, the UE connection process is implemented for lur interface. For the TMGI that indicates UE has left MBMS but not connected with UTRAN, the RNC deletes the relevant UE from the MBMS service context. Having processed all TMGIs, the RNC sends a “MBMS UE Connection Response” message to the CN, reporting the unsuccessful connection or to try to connect and the causes.
Disadvantages like poor performance when updating, excessive time spent on the establishment of a call, a complex system structure etc., lie in the existing system structure of 3GPP. So that standardization is being done to LTE by the 3GPP standardization organization. For the requirement of LTE, companies have proposed desired LTE system structures.
FIG. 5 illustrates an example of a desired LTE system structure. For example, the exemplary LTE system integrates the original functions of the RNC and Node B into a network entity (hereinafter called ERAN 502), and integrates the functions of SGSN and GGSN into a network entity (hereinafter called ECN 503). Here, the packet data compression protocol (hereinafter referred to as PDCP) is the original function of RNC. It can be placed either in the ECN or ERAN of LTE. In this way, by reducing network nodes, the system is simplified and system delay is decreased. 504 E-PDN is the external public data network, providing data resources. Here, the UE 501 is similar to UE 105 of FIG. 1.
One proposal is to divide the ERAN 502 into two network node equipments with one similar to the original function of Node B, the other similar to the original function of RNC, or with different function combinations for RNC and Node B. Some company suggests that the ECN is divided into the user plane entity and the control plane entity on the basis of function. In LTE, the function entity (the function part corresponding to original UTRAN) related to the access network is called EUTRAN (enhanced UTRAN).
According to the LTE system structure, the problem about transmitting MBMS service has not been solved with the existing standard. In the original structure, the MBMS data is transmitted from the BM-SC to the RNC where the UE locates through the GGSN and the SGSN. (For details, referring to FIG. 3 and the corresponding description). Here, the SGSN saves the MBMS UE context and the UE context (information such as the state of UE, the RNC where the UE in PMM connection mode locates, the Routing Area (hereinafter referred to as RA) where the UE in PMM idle mode locates). Therefore, the SGSN may find the downstream RNC. In the LTE, if not all ECNs offer data routing for each MBMS service, it is possible that ECN offering MBMS service is not the UE-registered one. In this case, the problem comes across the ECN that offers the MBMS service how to find the downstream nodes.